Cream of the Crop 22

home *** CD-ROM | disk | FTP | other *** search

/ Cream of the Crop 22 / Cream of the Crop 22.iso / os2 / et29b3.zip / readme.1st < prev

Wrap

Text File | 1996-10-04 | 50KB | 1,062 lines

This is the 'official' release of the 3rd beta of Electronic Teller 2.9, release version 2.9b3. CONTENTS: - Introduction (purpose behind beta) - Installation - Files - Migration (using pre-2.9 accounts in 2.9) - Importing (from QIF files) - Usage (usage issues discussed briefly) - Service Desk - Account Book - Creating Transactions - Postdating Transactions - Editing Transactions - Reconciling (Balancing) Accounts - Drag and Drop - First aid - Budgets - Reports - Transaction fees - Cheque printer - Searching & replacing INTRODUCTION ~~~~~~~~~~~~ This is the third and likely final ET beta. 2.9b3 contains some bug fixes as well as the rest of the functionality to bring it up to speed with 2.80a, noteably reports, transactions fees, an updated cheque printer, and a search-and-replace function. If you find a bug in this version, please report it by sending e-mail to phcaron@travel-net.com Also, try to provide as much information as you can about the bug: what led to it; can it be reproduced easily; how severe was it, etc. I'm also interested in knowing what users' opinions are. Many fundamental changes have been made to the interface in various aspects, all in the hopes of making ET a little more user-friendly. I may still have got things wrong-headed, so, please, don't be shy. Make your opinions known. Please note that the information in this file is by no means complete. It provides a *brief* introduction to 2.9 -- nothing more. INSTALLATION ~~~~~~~~~~~~ Unzip the files in the archive to a directory and run the install.cmd Rexx script. You will be asked to supply a destination directory. If you have 2.9b1 or 2.9b2 installed, you may install over that version. See the 'MIGRATION' topic below. NOTE: it's always a good idea to back up the ATM cards when installing over a previous version. If you are running a version earlier than the first 2.9b1, you must export your existing ET accounts and reimport them using the QIF Converter (see 'MIGRATION' below for additional information). FILES ~~~~~ Included in the archive are the following files. Depending upon your needs, some may be safely deleted. Files that are essential are prepended with an asterisk (*); runtime dynamic link libraries are not included, here: *etbook.exe Account Book etbuds.exe Budget graphs / printing etcalc.exe Calculator etcald.exe Calendar and reminder utility *etdesk.exe Service Desk etprnc.exe Cheque printer/designer etqifie.exe QIF Converter (essential in importing pre-2.9 accounts) restini.exe 'etdeskf.ini' INI restoration utility MIGRATION ~~~~~~~~~ A migration routine has been added to 2.9b2. It's primary purpose is to rearrange the data in the individual *.REC files for each ATM card to accommodate a larger cheque number (10 digits from 5) and to reverse the amounts for credit and liability accounts (something I overlooked in the first beta's QIF converter). Migration from 2.9b2 to 2.9b3 will only update the version number in the card's base.dat file. Automatic migration is relevant *only* to cards and accounts created with the first 2.9 beta. IMPORTING ~~~~~~~~~ To import your existing pre-2.9 ET account files, follow these simple steps (WARNING: do not have two copies of the program running concurrently; ET scans the task list for window titles in order to communicate with itself. If more than one copy exists, it will stop scanning at the first match, which may not be the newer version): 1) Open your existing pre-2.9 copy of ET i. Open the folder containing the account(s) to be exported. ii. Select the account to export. iii. Select 'Export to QIF...' from the 'Accounts' 'Maintenance' submenu. iv. Check the 'Regular transactions', 'Categories', 'Classes' boxes in the 'ET Converter' dialog. v. Click 'OK' to invoke the file dialog, and enter a filename. vi. Repeat steps i through v for each account to be exported. 2) Close ET and open version 2.9. 3) Recreate the folder(s) into which you want the newly-exported Accounts placed ('Cards -> New...'). 4) Access the newly-created card and invoke the QIF importer ('Cards -> Import QIF...'). The rest should be pretty self-explanatory with the exception of a few items. On export, ET will use the system's country settings in creating the date, so it is possible to have (for 31 Jan. 1995) one of the following three formats: 1/31/95 (US) 31/ 1/95 (European) 95/ 1/31 (Canadian) Rather than guess at what format is used in the QIF file (or assume that it corresponds to the system's country settings), the converter will display the first transaction in the Date Format dialog with the date parsed in accordance with the default (US) format. If it looks right, then click 'OK'. Otherwise, use the 'Up' 'Down' buttons to shift the date elements to reflect the format, and click 'OK'. If the format is incorrect, the converter will import records until it reaches a date with an element out of range. For example, if the US (mm/dd/yy) format was used when, in fact, the European (dd/mm/yy) format ought to have been used, as soon the converter reaches a date whose month exceeds 12, a fatal error will be raised and the conversion stopped. IMPORTANT QIF IMPORT STRATEGY: automatic (re)linking takes place during import. So, if you are importing 10 accounts, for example, and one account is linked to all 10 at some point, then one of two things will happen: 1) if the account to which a transaction is linked does not exist, a flag will be set for the transaction before it is added to the account being imported so that it can be easily retrieved when the link account is later imported. 2) if a link account already exists, one of the index files will be scanned for a possible match to relink the new transaction with an existing one. If a match does not exist, a new transaction will NOT be created. Instead, it will be logged in a separate window and displayed along with any other failed links when the last imported record is complete. For each failed relink, an entry in the window will appear as follows: SOURCE ACCOUNT: <Name of account being imported> TARGET ACCOUNT: <Name of account link account> DATE (mm/dd/yyyy): date of transaction in US format [NUMBER: cheque number] --| these are mutually exclusive [CODE: transaction code] --| and appear if applicable PAYEE/DESCRIPTION: transaction particulars AMOUNT: amount of transaction CLASS: (only if applicable) MEMO: (only if applicable) ---------------------------------------------------------------------- The information in the window can either be saved to file or printed. If it is deemed that this transactions should be rekeyed, then you will have some knowledge of what goes where. 3) If a match is found, relinking will take place automatically. In order for a match to be deemed valid, all but the category and amount fields of the source and link transactions must correspond exactly. If a match is not found with an exact date comparison, then the date will be expanded to the source transaction's month (that is to say, regardless of the actual day within the month). If still no match is found, the link will be considered failed, and the source transaction logged to the dialog mentioned above. Previously, I suggested that the order of imported accounts might prove important, and it has, but not for the reasons I gave, i.e. a time-saver. The QIF Converter was reworked again for the 3rd beta and the a number of accounts imported in random order. The outcome was always the same, and correct. USAGE - SERVICE DESK ~~~~~~~~~~~~~~~~~~~~ The Service Desk remains largely unchanged with the exception of sizeable container windows (position the mouse over the vertical bar, press RMB & drag). The 'Folders' paradigm has changed in 2.9 for two reasons: 1) folders don't quite make sense for a program called 'Electronic Teller', but an ATM (Automatic Teller Machine) card does; 2) I hope that moving away from the 'Folders' term will clear up the confusion that has existed in the past, e.g. Why can't I move accounts to another folder? etc. Like all ATM cards, ET's cards can be set up to access many accounts, and you can access other accounts on other cards if these are setup as such, but that's about the extent of it. At any rate, setting up new cards remains largely unchanged with the exception of terminology. Creating accounts is slightly different in two respects: 1) The date field has been replaced by a calendar. Selecting the date in the calendar is sufficient to inform ET that the initial transaction is to be dated that selected date. NOTE: initial transaction dates are treated loosely in 2.9. Although an account's creation date can be 1 Jan. 1996, for example, with a starting balance of $1.00, a subsequent addition to the account on 31 Dec. 1995 to the amount of $2.00 will transfer the creation date from Jan. 1 to Dec 31 as well as the initial balance. 2) Closing the notebook creates the account. This is to ensure that the notebook is more CUA compliant. If the account name entryfield is left blank, no account will be created. USAGE - ACCOUNT BOOK ~~~~~~~~~~~~~~~~~~~~ The Account Book has changed dramatically from an end-user point of view. The single container has been placed into a notebook and replaced by an owner-drawn listbox. The notebook will contain pages for each year a transaction in the account exists, from latest to earliest. This means that, for an account with transactions spanning 1995 to 1996, two pages will be initially displayed in reverse order (1996, 1995). All records for 1996 will be loaded into the listbox on startup. The 1995 records will be loaded only if the notebook page is selected. The amount of records loaded per pass is determined by the size of the listbox window. If, for example, it is estimated that the window will contain 50 records, the records will be enumerated approximately 50 at a time (the date determines the actual number, but it will never be less than the amount of records that can fit in the visible portion of the listbox) with a one-half second pause in between each load, until all records are loaded. The one-second pause exists to allow the user to perform duties while the loading process is underway, so that he/she doesn't have to sit idly while ET is churning away. ET manages this by serializing access to the data files. Although tests have shown pretty good stability, here, it's a good idea not to try invoking a function before something appears in the listbox. Many of the icons have also been changed. Two reasons for this. First of all, I lost all my old icons following a complete C: drive failure. Second, the old ones were, well frankly, somewhat ugly. If in doubt, watch the status area of the window while moving the pointer over the icon. It should tell you what its purpose is. Some buttons in the button bars are also somewhat specialized, providing access to different functions depending upon the state of the Ctrl key when the button is clicked. The trashcan button, for example, will delete transactions or, if deleted transaction are selected, shred them. If the Ctrl key is depressed when this button is clicked, the selected transactions will be restored, or undeleted. Again, watch the status area for clues. A word about shredding: SHREDDED RECORDS CANNOT BE RESTORED. USAGE - CREATING TRANSACTIONS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Major changes, here, too. The notebook has been replaced by a single and more straightforward (I hope) dialog box. Moreover, it is no longer possible to add transactions to multiple accounts in a single session. All transactions are added to the account from which the dialog was invoked (or the selected account if invoked from the Service Desk). To create a transaction (from the Transaction dialog), follow these steps: 1) Double-click on a calendar date OR go to the date field and use the Up/Down; Ctrl+Up/Ctrl+Down keys to scroll to the desired date OR enter the date manually. If you opt for the 3rd option, enter it correctly, in accordance with your system's country settings, i.e. mm/dd/yyyy or dd/mm/yyyy or yyyy/mm/dd. 2) Go to the Number field and enter either a cheque number of a transaction code, i.e. ATM. Line completion is available here, so if ATM already exists, typing 'A' will expand the field to to first code matching that prefix. OR if a cheque, simply enter '!' (without the single quotes). This will assign the next cheque number in the series to the Number entryfield when you go to another field. OR press the F2 key to get a popup listbox of existing transaction codes OR right-click anywhere in the entryfield for the list OR press the Up/Down keys to scroll the existing list Any numeric value entered into this entryfield is considered a cheque. A numeric value is anything that begins with a number, e.g. 123ABC will be interpreted as cheque #123. On the other hand, ABC123 will be considered a code in its entirety. 3) Go to the payee field and enter the payee or particulars. If a memorized transaction exists for this information, the field will be expanded to contain that information (as well as the credit or debit, category, class, and memo fields). If the transaction code field is blank, it, too, will be given a value if one exists for the memorized record. OR press F2 to get a list of existing memorized transactions OR right-click in the window for a view of that list. OR press the Up/Down keys to scroll the existing list If a memorized transaction exists, is displayed, and contains a cheque number, you will be asked if you would like the next cheque number in the series applied to the item. Replying 'Yes' will assign the next number to the Number field. 'No' assigns the memorized number to the Number field. If you choose not to accept the memorized transaction, press F3 to undo the changes made by the expansion. All but the 'Particulars/Payee' fields will be returned to their state prior to the expansion. 4) Enter a value in the Credit field OR enter a value in the debit field. If both fields are 0, you will be requested to confirm the transaction before it is entered into the container. If both fields contain a value that is not zero, the transaction will be rejected. 5) Tab to the category field and enter your data (line completion applies) OR press F2 for a list of existing categories OR right-click anywhere in the entryfield for a list of existing categories OR press the Up/Down keys to scroll the existing list 6) Tab to the class field and enter your data (line completion applies) OR press F2 for a list of existing classes OR right-click anywhere in the entryfield for a list of existing classes OR press the Up/Down keys to scroll the existing list 7) Tab to the memo field and enter your data 8) Click 'Append' to create a regular transaction OR click 'As Split' to create a split transaction for the selected regular (or parent) record in the container Splits must have a valid parent record selected in the transaction container. If none is selected or exist, the 'As Split' button will be disabled. When a split is created, it will be added to the container as a child of the parent, in standard OS/2 container usage, i.e. a + enclosed within a box will appear to the left of the parent container record. Expand the container to view, or edit, or 'Remove' splits. New records that appear in the transaction container are not actually written to file until the 'OK' button is clicked to dismiss the dialog. This allows you the opportunity of making changes, removing records, etc. before actually committing the records to file. Once a record has been 'Append'ed to the container, you can then elect to memorize it (by checking the 'Memorize' box) or postdate it (by checking the 'Postdate' box). USAGE - POSTDATING TRANSACTIONS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Postdated transactions appear in the account ledger using a half-toned text attribute -- it's slightly more difficult to read, but *is* readable and clearly denotes a postdated entry. The amount of the transaction is not tabulated into the overall balance. To postdate a transaction, first select it from the transaction container, and click the 'Postdate' checkbox. If the transaction is successfully postdated, the box will remain checked. You can either remove postdating by unchecking the box, or edit the postdated options by clicking the 'Edit postdate...' button. Postdating transactions is somewhat different from previous versions of ET. Most important is that postdated options are saved in 'setups'. In order to postdate a record, a setup must either already exist, or one must be created. When the Postdate dialog is invoked on a transaction that has not yet been postdated, it's 'Particulars/Payee' information will be displayed and suggested as a postdate setup name. If such a setup already exists, the options previously defined will be preselected. You can either leave them unchanged or make alterations. WARNING: any changes made to a setup has a card-wide affect. That is to say, if you change the frequency of an existing setup entitled 'First of Month', all records making use of that 'First of Month' setup will be affected. Similarly, if you delete the 'First of Month' setup, all records making use of that setup will no longer be postdated! NOTE: the calendar/reminder utility shares the postdate dialog but its setups are independent of all ATM cards. IOW, deleting a reminder setup has no effect on any transaction in any account on any card. All postdate options are preserved when the dialog is dismissed. So, making changes to an existing setup are not preserved if the 'Cancel' button is clicked. Similarly, options for a new setup are preserved when 'OK' is clicked. To create a new setup, enter a name in the combobox and click 'Add'. To delete an existing setup, select it from the combobox and click 'Delete'. To change a setup's name only, select it in the combobox, make the necessary changes, and click 'Change'. There are now four possible postdate frequency options: 1) ONE TIME Select this option if the transaction is postdated but is not to be repeated after the expiry date is reached. 2) SIMPLE This is the simplest to set up. Any combination of the three spin- buttons (Days, Months, Years) is permitted. So, setting them to: Days <1> Months <2> Years <3> will advance the transaction's next date to 3 years, 2 months, and 1 day from the moment day it becomes due. The maximum values for each spinbutton are: Days: 31 Months: 11 Years: 99 3) RECURRING DATE There are two spinbuttons in the 'Date options' groupbox with possible values enclosed within angled brackets: On the <1st to 31st> of every <month>, <2nd to 11th month>, <Jan to Dec> The first spinbutton represents an actual monthly calendar date. If you select the '31st' obviously not every month has 31 days. ET will assume that you mean on the last of month and adjust the next date accordingly. The second spinbutton can be set to repeat monthly '<month>', every <x> month, or every specific month '<Jan> ... <Dec>'. The syntax should guide you in creating a valid postdated transaction. 4) RECURRING WEEKDAY This is the most flexible of all, but also the most difficult to setup. There are three spin buttons, with possible values enclosed within angled brackets: On <1st to 4th>, <last> <Sun to Sat> of every <week>, <2nd to 4th week>, <month>, <2nd to 11th month> Again, let the syntax be your guide. If you are creating an entry for a bi-weekly paycheque, deposited into your account every second Friday, then you would spin the buttons as follows: On <---> <Fri> of every <2nd wk> If, on the other hand, your account is deducted on a specific day of the month, every month, and, if that day happens to be the last Monday of the month, you would spin the buttons as follows: On <last> <Mon> of every <month> A number of verifications are made before postdated options are accepted: 1) the transaction's initial date of the month must correspond to the postdated date of the month, where applicable. 2) the transaction's week in the month must correspond to the postdated week option, where applicable. 3) the transaction's weekday must correspond to the postdated option's weekday, where applicable. USAGE - EDITING TRANSACTIONS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To edit one or more transactions, select them from the Account Book, and select the 'Edit...' menu item OR press <Enter> OR press and hold the Ctrl key and click the transaction button OR invoke the transaction dialog and drag selected records into the transaction container while holding the 'Ctrl' key Any of these actions will invoke the Transaction dialog into which the selected records will be displayed in the container. Double-click on the records to recall their values into the entryfields, make the changes and click 'Change'. Changes are not actually committed to file until the dialog is dismissed by clicking the 'OK' button. You can, if you wish, add additional records by following the above procedures or by holding the Ctrl key and dragging one or more transactions from the Account Book container into the Transaction dialog's container. You can also also create additional records at this time by following the instructions outlined in the 'Usage - Creating Transactions' topic. There is no limit on the number of transactions that can be created and/ or edited in one session. The only limitation is that all transactions are destined for the same account, and additional instances of the dialog are not permitted. USAGE - RECONCILING AN ACCOUNT ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Account reconciliation has been greatly simplified, as well. The cumbersome dialog of pre-2.9 has been replaced by a more user-friendly version. The dialog itself is divided into two parts: 1) entryfields, 2) listbox. The entryfields are used to specify certain necessary pieces of information required for a valid reconciliation: Previous balance: specifies the ending balance at the last recon- ciliation, or the accounts starting balance if working from a new account, or the sum of all cleared transactions if working from an imported QIF file Increase by: specifies all credits that should be applied to the account being reconciled, such as interest payments made to you during the period between the last reconciliation and the reconciliation date or any other item that increases the account's balance. Decrease by: specifies all debits that should be applied to the account being reconciled, such as fee payments deducted from your account or charged to your account; in short, all items that deduct from an account's balance. New balance: specifies the balance as it appears on your statement. Statement: is the date upon which the reconciliation is to take place. Typically, this will mirror the date of the statement. When these data are entered, you can begin clearing transactions by double-clicking on those that are to be cleared (or selecting them and pressing <Enter>). Cleared transactions are denoted by a check mark to the left of the transaction. To unclear a transaction, simply double-click on it a second time. (Un)clearing a transaction automatically moves the cursor to the next record. If there are more transactions in the listbox than will appear in the window, the window will be scrolled so that it is situated at the second-to-top-most position in the listbox (this may take some getting used to). As transactions are cleared, the (+), (-), and (=) status areas of the window will be adjusted to reflect the total credits, debits, and balance respectively. When the (=) area's amount matches that entered in the 'New balance' entryfield, ET will consider the reconciliation to be accurate and will sound a beep. Any difference between these two amounts will be reported when the 'Reconcile' button is clicked, allowing you to abort the final stages. Of course, adjust the 'New balance' manually will fool ET into thinking that all is well, but this is not a recommended practice. The oversight is intentional, however -- a sort of fudge factor that is there if absolutely necessary. USAGE - DRAG AND DROP ~~~~~~~~~~~~~~~~~~~~~ Version 2.9 makes extensive use of OS/2's drag & drop capabilities. ET complies with the standard OS/2 drag & drop options, e.g. Move = drag button Copy = Ctrl + drag button Link = Shift + Ctrl + drag button Here, briefly, is a list of what can be done: Move ... permitted to any opened account book on the same card ... permitted to any account icon in the Service Desk on the same card ... disallowed if the source and target accounts are the same (obviously) ... permitted when dragging an ATM card or selected accounts to the shredder Copy ... permitted to any opened account book or account icon in the Service Desk, including the source of the drag, but not to accounts on different cards ... permitted when dragging selected transactions to the transaction dialog container. ... permitted when dragging an ATM card or selected accounts to the shredder Link ... see below ... permitted when dragging an ATM card or selected accounts to the shredder Links require special consideration given the fact that a listbox is used rather than a container, which means that there is no sure way of knowing if a record has been dropped on a record or white space. Here are the following rules for valid linking: 1) If the source window has multiple records selected, the target must not have any selected. An accepted drop will copy the selected source records into the target account and link them. 2) If the source window has one record selected as does the target window, no new record will be created; rather the source will be linked to the target and neither record values will be altered, with the exception of the category which will reflect the linked account's name within square brackets. The long and the short of this is: if you want to link with an existing transaction in the target account, select it before initiating the drag. If you want to duplicate records from the source in the target account, deselect all records in the target and select the relevant records in the source before initiating the drag. FIRST AID ~~~~~~~~~ If your account(s) appear to suffer irrevocable damage, have a look at the first-aid option from the Service Desk. Selecting an account and invoking first aid will allow you to repair three things: 1) ending balance or ('Sums') 2) damaged index files ('Indices') 3) forward balance error ('Balance') Electronic Teller maintains a sums table for every year an account has a transaction, and displaying a running balance is largely contingent upon the accuracy of this table. If your running balance appears to be off, click the 'Sums' button in the first aid dialog. To speed things along, ET uses index files. The bulk of the data, however, is kept in the *.REC file in the ATM card's directory. If this key file ever becomes corrupted, you have only a backup to fall back upon. If, on the other hand, one or more index files become corrupted, click the 'Indices' button in the first aid dialog. This will read the entire *.REC file and reconstruct the indices, sums table, and forward balance. Reconciliation depends a great deal upon an accurate forward balance (your initial balance when the account is first created or your last reconciled balance). This can be repaired by clicking the 'Balance' button in the first aid dialog. Of course, there's nothing as safe as a backup, and ET makes this process even safer by creating an ascii file of the card's entries from the etdeskf.ini file -- a global ATM card file used to save such things as the sums table I mentioned above. This ascii file can be used to reconstruct a card's INI entries with the 'restini.exe' utility. What this utility will do is read the 'etdeskf.rc' file, restoring code handles and names, memorized transaction handles and structures, category handles and structures, class handles and names, cheque design structures, postdated setups, as well as the budget entries (budgeted and actual amounts) and the accumulated bank fees. Do not rely on this utility completely, because it is only as good as the last backup. BUDGETS ~~~~~~~ Budgets are complete. If budgets exist for your categories in the QIF file, then they will be automatically imported by the QIF converter. Note, however, that ET will permit multiple budgets, based upon a year. So, it is possible, therefore, to have a budget for a subcategory named 'Utilities:Electricity' for both 1995 and 1996. During import, the current system year is always used. To create a budget, you must invoke the Settings notebook (Card -> Settings from the Service Desk), (Records -> Settings from the Account Book), or 'Settings' in the Transaction dialog. The page labelled 'Budgets' contains a number of controls. Simply select the category for which the budget is to be created and enter the appropriate amounts in the twelve entryfields. Click 'Save' to save the budget amounts for that category. You can copy an entire category budget from one year to another by selecting the budget and selecting the target year in the second spin button. Click 'Copy' and then 'Save' to preserve the budget. 'Undo' will always revert to the previous amounts. Budget graphs and printing are available from the Service Desk once an ATM card has been accessed. Upon startup, the 'Summary' graph will be set as the default. Clicking the 'ref' button to the right of the 'Trans. Year' spin button will read in the relevant data from the account(s) and begin plotting the graph. There are three types of graphs available: 1 - Income or Expense Category This will display a breakdown of the budgeted and actual amounts for a category throughout the entire 'Trans. year'. The 'Budget year' will be used for purposes of comparison. 2 - Income or Expense Group Depending upon the list of categories displayed, this option will total the budgeted and actual amounts for each displayed category and display a breakdown of those totals for each month of the 'Trans. year', using the 'Budget year' budget. 3 - Summary This graph will display a total of the following six items: i - Budgeted Income ii - Actual Income iii - Budgeted Expense iv - Actual Expense v - Budgeted Income less Expense vi - Actual Income less Expense To view graph #1, simply double-click on the desired category in the listbox. To view graph #2, click the 'Group' button. And, to view graph #3, click the 'Summary' button. To apply a budget defined for another year to the transac- tions for a specific year, spin the 'Budget year' button and click the 'ref' button to the right of that button to refresh the display. To view results for a specific transaction year, spin the 'Trans. year' button and click the 'ref' button to its right to refresh the display. Depending upon the amount of records for a given year, refreshing the transaction year can take anywhere from a few seconds to a minute or more. The process is threaded, and can be cancelled at any time by clicking the 'Close' button. Summary and Group graphs are also threaded and can also be cancelled by clicking the 'Close' button. Only the accounts which are selected in the 'Accounts' listbox will be included into the actuals amounts for both graphing and printing. To print a budget, click the 'Print...' button, select a printer (the printer will be remembered from session to session), select what type of category to include in the budget report (either Income and/or Expense), and, if you would like empty budgets (those that have neither a budget or actual amount for the entire year) included, check the 'Include empty' box. Click 'Print' to begin the process. Click 'Cancel' to abort the print job. What is included in a budget graph and report is any transaction with a valid category. This includes regular and split transactions. ET does not differentiate between a regular and split transaction, so if a category is specified for both the regular transaction and each split, duplication will occur. What is not included in the actuals totals are records that have been flagged for deletion or postdated transactions. REPORTS ~~~~~~~ Creating a report is a simple matter of selecting the accounts from the ATM card, selecting the desired type, and specifying a 'From:' and 'To:' date range. This is commong to all report types. Some types require additional user-interaction. Five report types are available: 1) Transaction 2) Budget 3) Cheque Usage 4) Unreconciled Records 5) Transaction Fees TRANSACTION reports list account contents in the following order: ~~~~~~~~~~~ Date Code Description Memo Category Clr Amount Date contains the transaction's date, formatted in accordance with the system's country settings. Code contains either the transaction's cheque number of code, e.g. ATM. Description is the transaction's payee or particulars. Memo is what it states Category is a combination of category:subcategory/class or whatever will fit on the line. Clr will be either blank if the transaction is neither cleared nor a split; 'X' if the transaction is cleared; '-s-' if the transaction represents a split. Amount is a signed amount A number of subtotalling options for this report are available. These are: 1) None 2) Weekly 3) Two weeks 4) Half month 5) Monthly 6) Quarterly 7) Six months 8) Yearly 9) Category (family) 10) Category (single) 11) Class 12) Payee The 'Category (family)' option subtotals by an entire category type, e.g. transactions using, for example, "Utilities:Electricity" and "Heating:Electricity" will be subcategorized individually. The categories that are included are selected by the user, and only those that appear in the selected account(s) are made available. The 'Category (single)' option subtotals by individual category items. For example, if the 'Electricity' subcategory were selected, the two category families "Utilities:Electricity" and "Heating:Electricity" would be subtotalled together, since they share a common child, i.e. "Electricity." Again, the categories that are included in the report are user-selected. Subtotalling by Class and Payee is also user-selectable. That is to say, only those classes and payees for which a transaction exists will be made available, and those that are selected will be included in the report. BUDGET reports subtotal by category thus: ~~~~~~ Category Budget Actual Difference Mth Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec The first step in creating a budget report is selecting the categories that are to be included, both from the 'Income' and the 'Expense' lists. If you wish to omit a category type entirely, simply uncheck the box beneath the list. The next step is selecting the months that are to be included for each budget and actual months. These are preselected based upon the previously selected date range, but can be changed prior to generating the budget report. Any unselected month will be assigned budget, actual, and difference values of 0 to avoid skewed or incorrect totals. CHEQUE USAGE reports make use of the same format as the Transaction report. ~~~~~~~~~~~~ A Cheque Usage report picks all the transactions within the date range that contain a valid cheque number. Numbers are listed in reverse order and any missing or duplicate cheques are enumerated at the bottom of the report. A special note about duplicate cheques: if a link exists for a cheque, and both the source and link accounts are included in the report, then a duplicate entry will appear. This erroneous duplication could be avoided, but would require additional code to overcome what could be seen as a feature. UNRECONCILED RECORDS reports make use of the Transaction report format. ~~~~~~~~~~~~~~~~~~~~ This report lists all records that have yet to be cleared. Rather than leave the 'Clr' column blank, three dashes (---) appear so that a manual checking can be performed if desired. TRANSACTION FEES reports makes use of Electronic Teller's transaction fees ~~~~~~~~~~~~~~~~ The Transaction Fees report also makes use of the Transaction report format, except each defined transaction code, e.g. ATM, WIT, etc. is grouped on a per-month basis, and after each month for each code, a breakdown like the following is shown: (1) ATM transactions for August 1996: 10 (2) Free transactions per month: 3 (3) Free exceeded by: 7 (4) Minimum monthly balance: 700.00 (5) Minimum balance required: 1,000.00 (6) Amount owing if balance met: 3.50 (7) Amount owing if balance shortfall: 10.00 ======== (8) Total owing: 10.00 The numbered lines are as follows: (1) is the number of codes found for the month; (2) the amount of free transactions defined in the Settings notebook for this code per month; (3) the number of transactions exceeding the free count; (4) the account's minimum monthly balance; (5) the minimum monthly balance required to qualify for 'Free' transactions, as defined in the Settings notebook; (6) the amount owing if the minimum monthly balance is met (amount * (total count - exceeded count)); (7) the amount owing if the minimum monthly balance was not met (amount * total count); (8) the total amount owing for the given code for the given period -- either (6) or (7) but not both. In the above example, it is assumed that each 'ATM' transaction costs 1.00 on a balance shortfall and .50 if the balance is met. Ten transactions were found with a minimum monthly balance of 700.00, 300.00 less than the required minimum. Because the miminum balance has not been met, the cost associated with the shortfall is assigned to the 'Total owing' (8) row, or 10.00. If the balance had been maintained, then the amount owing would have been 3.50 ( .50 * ( 10 - 3 ) ). At the end of the report, all the (8) are tabulated to present an overall total of all transaction fees for the defined period. TRANSACTION FEES ~~~~~~~~~~~~~~~~ To create transaction fees, select an account from the Service Desk or open an account book, and invoke the settings notebook. The final page, entitled 'Fees' will be displayed. Simply turn to that page. You will see a list of all codes defined for the account. Select then codes for which a fee is to be created, and tab to the first of the four entry fields below. These are: (1) Free items per month: (2) Minimum balance req'd: (3) Cost if balance not met: (4) Cost if balance met: (1) represents a count of items for which no charge is attached if the minimum monthly balance is met. In other words, this item affects only the 'Cost if balance met' item. (2) represents the minimum monthly balance used to determine if the count of items should be adjusted and whether a cost should be applied to the '...balance not met' or '...balance met' items. (3) represents the charge per transaction if the minimum monthly balance is met (cost * (total count - free count)). (4) represents the cost if the minimum monthly balance is not met ( cost * total count). Transaction fees are relevant to individual accounts in individual ATM cards. CHEQUE PRINTER ~~~~~~~~~~~~~~ When the cheque printer dialog is first invoked, two listboxes appear with associated buttons beneath each. The left box, 'Queued cheques' contains a list of all cheques transactions that were selected prior to invoking the printer. 'Designs' contains a list of all existing designs. Initially, this listbox will be empty. In order to print cheques, a design must first be created. Do so by following these steps: 1) Click 'Create...' 2) Assign the design a name ('Design:') 3) Specify the number of cheques per page. This number is used in both determining the amount of space between cheques on multiple cheques printing and in deciding when to send the printer a new page command. Possible values range from 1 to 5 or continuous. The 'continuous' option means, simply, that no new page code will be sent to the printer; instead, it will be assumed that the cheques are not on indidivual sheets of paper but on continuously fed paper. 4) Determine the dimensions of an individual cheque in millimeters. these are important in two respects: (1) the width will determine the amount of space cheque fields can be dragged. If you require an unusual left margin, you can increase the width of the cheque to create greater horizontal space. The height is important in determining the spacing in between cheques if more than one cheque exists per page. 5) The 'Window scale:' is used solely to accomodate the design window to your display so that the size can more closely match the actual cheque dimensions. On my display (small font @ 1024x768), the scale of 4 is ideal. Possible values range from 1 to 10. 6) If the cheque number is to be printed, check the 'Print cheque number' box. 7) If the dates are to be combined, e.g. '1 Jan 96' rather than '1 Jan' and '96' as separate fields, check the 'Combine date fields' box. 8) If your cheques accomodate stubs, check the 'Cheque includes stub' box. 9) Drag the fonts you want to use for the individual cheque fields to the Cheque Design cheque fields. Because the font use will affect the positioning of the printed item, it's a good idea to do this before actually dragging fields. 10) Begin positioning the individual fields. Bear in mind that the 0x0 coordinate corresponds to the lower left-hand side of the window. So, measure your fields from bottom left to top right. Bear in mind, also, that the X: and Y: coordinates are merely an approximation; and so this is mostly a trial and error sort of endeavour. To test your design, click the 'Test...' button on the 'Design Setup' dialog. The status area of the window will inform you of a field's position and font as the mouse is moved over the field. The 'X:' field reports the item's horizontal position, from the left-hand side of the window; the 'Y:' field reports the item's vertical position from the bottom of the window. Once you have created one or more designs, select the one you want to use for the printing session, and click 'Print...' If you wish to remove any cheques from the print list, simply select them and click 'Remove'. As each cheque is spooled, a check mark will appear to the left of the item. SEARCHING & REPLACING ~~~~~~~~~~~~~~~~~~~~~ To search and optionally replace transaction data, click on the magnifying glass in an account book. This will invoke the 'Search and Replace' dialog from which a search is defined and an optional replacement string specified. Any of the following 6 transaction fields can be searched: 1) Number or Code 2) Payee or Description 3) Amount 4) Category 5) Class 6) Memo And, any of the following 3 transaction status options can be applied: 1) Deleted 2) Postdated 3) Voided The desired option is selected from the 'Field' combination box. If the 'Status' is set to 'None', then no filtering is performed during a search. That is to say, any record matching the search criteria, regardless of whether it is cleared, deleted, postdated, uncleared, or voided, will be included in the results list. If a status is specified, then only those transactions which meet the status requirement will be considered for inclusion into the results list. If a 'Search' criterion is also specified, then the transactions in question must also meet thosee requirements. NOTE: that no search criterion need be entered when searching for transactions of a given status. If the 'None' status is selected, then a search string must be provided in order for the search to take place. Next, a date range for the search is entered. The 'to' date is inclusive. As elsewhere in Electronic Teller, the [Ctrl] PageUp/ [Ctrl] PageDown keys can be used to cycle the date by [month] and day. The 'Search' is where the search string is entered. If you are searching a code, payee, category, or class, you can right-click in the search field (or tab to it and press F2) to get a list of existing items. Alternatively, you can enter any complete or substring. If you wish to limit the search by case or exact match, check the appropriate boxes beneath the 'Search' entryfield. If the case checkbox is left unchecked, the search and found strings will be converted to uppercase prior to examination. If the exact box is left unchecked, the found string will be searched to determine if it contains the substring specified by 'Search'. Thus, a payee search of 'wit' will result in a hit for all payees containing that string, e.g. withdraw, withold, Joe Witaker, etc. If you wish to search split transactions, ensure that the 'Omit splits in search' box is left unchecked. By default, splits not included in searches, although they are not available if specifying a status criterion, since, by definition, if the parent is deleted, postdated, or voided, so, too, are the splits. Before any 'Replace' can take place, the search must first be executed. A replace can then proceed only if at least one 'hit' was made. If you attempt to replace a code, category, or class with an item that does not exist, you will be asked if you would like to create that item. If you answer No, the replacement will not take place. The 'Options' menu contains a number of options, much like those that are found in all account books' 'Record' menu. You can, for example, delete or undelete, shred, void or restore, create or edit transactions. The same text attribute and colour sequence used in account books is also used in results list box.